zlib: remove _closed
#6574
Closed
zlib: remove _closed
#6574
+18
−14
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is purely cleanup and carries no visible behavioural changes. Up to now, `this._closed` was used in zlib.js as a synonym of `!this._handle`. This change makes this connection explicit and removes the `_closed` property from zlib streams, as the previous duplication has been the cause of subtle errors like nodejs#6034. This also makes zlib errors lead to an explicit `_close()` call rather than waiting for garbage collection to clean up the handle, thus returning memory resources earlier in the case of an error.
|
Even though this was an underscored property, it should probably still go through a deprecation cycle. |
Fishrock123
added
the
semver-major
|
You can de-semver-major-ize this PR by keeping A separate PR can remove it (or print a deprecation warning if it's accessed, or whatever the correct first deprecation step is in this situation). |
|
Eh, yes, I’m adding a getter for |
Add a getter for `_closed` so that the property remains accessible by legacy code.
|
Done. The OS X CI failure looks very unrelated, but I don’t recall it being mentioned as flaky anywhere, if anyone’s curious. |
addaleax
removed
the
semver-major
|
OS X thing sure looks unrelated. Maybe run a second CI just to make sure? Stranger things have happened, although not often. :-) |
|
LGTM if the CI is happy. |
|
LGTM but if you happen to know of any modules that use zlib we may want to get those into citgm to make sure these kinds of changes don't have unintended drawbacks /cc @thealphanerd |
|
Hmm… there are each with > 500k npm downloads/month, I think that’s something? |
|
Works for me! |
|
I think this can be landed without an extra citgm run, but ping @thealphanerd … interested in adding the modules from above to the list? |
|
I have a branch with the modules added to the lookup. I'll get a citgm run
later tonight or tomorrow
|
|
Oh, okay then, sorry for bothering. ;-) |
|
Not bothering at all. Totally spaced on following up in this thread 😊
|
|
Landed in b53473f |
addaleax
added a commit
that referenced
this pull request
May 17, 2016
This is purely cleanup and carries no visible behavioural changes. Up to now, `this._closed` was used in zlib.js as a synonym of `!this._handle`. This change makes this connection explicit and removes the `_closed` property from zlib streams, as the previous duplication has been the cause of subtle errors like #6034. This also makes zlib errors lead to an explicit `_close()` call rather than waiting for garbage collection to clean up the handle, thus returning memory resources earlier in the case of an error. Add a getter for `_closed` so that the property remains accessible by legacy code. PR-URL: #6574 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
Fishrock123
pushed a commit
that referenced
this pull request
May 23, 2016
This is purely cleanup and carries no visible behavioural changes. Up to now, `this._closed` was used in zlib.js as a synonym of `!this._handle`. This change makes this connection explicit and removes the `_closed` property from zlib streams, as the previous duplication has been the cause of subtle errors like #6034. This also makes zlib errors lead to an explicit `_close()` call rather than waiting for garbage collection to clean up the handle, thus returning memory resources earlier in the case of an error. Add a getter for `_closed` so that the property remains accessible by legacy code. PR-URL: #6574 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
|
@addaleax lts? |
rvagg
pushed a commit
that referenced
this pull request
Jun 2, 2016
This is purely cleanup and carries no visible behavioural changes. Up to now, `this._closed` was used in zlib.js as a synonym of `!this._handle`. This change makes this connection explicit and removes the `_closed` property from zlib streams, as the previous duplication has been the cause of subtle errors like #6034. This also makes zlib errors lead to an explicit `_close()` call rather than waiting for garbage collection to clean up the handle, thus returning memory resources earlier in the case of an error. Add a getter for `_closed` so that the property remains accessible by legacy code. PR-URL: #6574 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Checklist
Affected core subsystem(s)
zlib
Description of change
This is purely cleanup and carries no visible behavioural changes.
Up to now,
this._closedwas used in zlib.js as a synonym of!this._handle. This change makes this connection explicit and removes the_closedproperty from zlib streams, as the previous duplication has been the cause of subtle errors like #6034.This also makes zlib errors lead to an explicit
_close()call rather than waiting for garbage collection to clean up the handle, thus returning memory resources earlier in the case of an error.CI: https://ci.nodejs.org/job/node-test-commit/3184/